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SUMMARY 

Problem 

The  Office  of  the  Manager  of  the  National  Communication  System 
(NCS)  requires  timely  accurate  information  about  communications  re- 
sources during  national  disasters.  This  led  to  the  development  of  a 
pair  of  decision  support  systems  (DSS)  for  the  National  Emergency 
Management  teams.  These  systems  are  the  Emergency  Preparedness 
Management  Information  System  (EPMIS)  and  the  Fly-Away  Management 
System    (FAMIS). 

This  report  covers  the  FAMIS  system.  FAMIS  currently  exists  as  a 
prototype  written  in  BASIC  and  implemented  on  portable  Otrona  micro- 
computers. The  prototype  is  in  an  early  stage  of  development.  It  has 
been    useful   for  defining   the  final   system. 

Now  that  the  concept  has  been  developed,  it  is  time  to  move  beyond 
the  prototype  stage.  NCS  must  start  a  disciplined  development  effort. 
The  remainder  of  this  report  deals  with  the  definition  of  the  problem 
and   the   process   of   setting    up   a   development  effort. 

Objective 

There  were   several   objectives    in   this   project.      They   were: 

1.  Determine   how  to  speed   up  the  current   FAMIS   prototype. 

2.  Determine   how  to   structure  and    integrate   EPMIS   and    FAMIS. 

3.  Suggest  approaches   to   long   term    FAMIS    structure   and   design. 

4.  Suggest  administrative  approaches   for   EPMIS/FAMIS. 
Approach 

In    performing   this   work,    I    did   the  following: 

1.  Analyzed    FAMIS   code. 

2.  Rewrote   portions   of   FAMIS   code. 
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3.  Reviewed  reports  from  NCS  and  Booz,  Allen  and  Hamilton  on 
the   EPMIS/FAMIS   system. 

4.  Reviewed    related    DSS   and   system   development   literature. 

5.  Reviewed   computer  software  for   useful   packages. 

Results  and  Conclusions 

The  work  on  the  EPMIS/FAMIS  system  has  reached  a  critical  point. 
Management  needs  to  establish  a  clear  set  of  goals  and  priorities  for  the 
system   development  to   succeed.      My   specific    recommendations   are: 

1.  Establish   a    set  of  goals   for  the   system. 

2.  Design    decision   modules   to   implement  these  goals. 

3.  Design   a   database  to   support  the  decision   modules. 

4.  Give  contractors  more  guidance  in  pursuit  of  these  goals. 
Booz,  Allen  and  Hamilton  have  produced  little  useful  in  the 
EPMIS  database  design.  Until  they  do,  all  development  on  both 
EPMIS   and    FAMIS    is   effectively   blocked. 

5.  Improve  the  FAMIS  prototype  for  short  term  demonstration  pur- 
poses   in   the  following   ways. 

a)  Compile  the   FAMIS   prototype. 

b)  Move  to  a   hard   disk  environment. 

c)  Use  on    faster  micro. 

d)  Speed    up   the  graphics. 

e)  Use   as   a   test   bed   for  future  enhancements. 

6.  Design    an    administrative   support   structure  for    FAMIS. 

a)  Define  goals   for   integrated    EPMIS/FAMIS. 

b)  Develop   administrative   procedures   for  data   management. 

c)  Try     to     achieve     high     degree     of     interoperability     between 
EPMIS   and    FAMIS. 


d)  Plan  to  operate  in  a  permanent  prototyping  mode.  This 
means  that  a  capable  systems  team  should  be  able  to  make 
fast  changes  to  the  system  without  going  through  a  whole 
systems   development  cycle. 

e)  Develop  a  software  team  used  to  quick  response  and  devel- 
opment. 

7.        Implement  the  following   hardware  and   software   steps. 

a)  Choose  compatible  software  for   EPMIS/FAMIS. 

b)  Design  for  interoperability  between  EPMIS  VAX  system  and 
FAMIS   micro  system. 

c)  The  best  system  choices  are  the  C  language  for  custom  ap- 
plications, SQL  for  database  and  FOCUS  for  unstructured 
queries   into  the  database. 

d)  Replace  Otrona  with    hard   disk  80286  based   portable. 

e)  Plan   to   replace  the   replacement   in   a   few  years. 

f)  Encrypt  the   FAMIS   database. 

g)  Watch   developments    in    laser  disks. 

Future   Research   Considerations 

Much  needs  to  be  done  to  make  EPMIS/FAMIS  a  truly  useful  system. 
We  do  not  have  the  resources  needed  to  do  everything  required.  That 
will  take  years.  I  have  outlined  the  steps  NPS  can  accomplish  in  the 
next  year. 

1.  Design  a  data  dictionary  structure  for  capturing  data  about  the 
database. 

2.  Produce  an    initial    FAMIS   database  design. 

3.  Produce  a  compiled  C  version  of  the  current  FAMIS  file  based 
prototype. 

4.  Produce  a  "proof  of  concept"  prototype  of  a  database  oriented 
set  of  FAMIS  routines  using  an  80286  based  computer,  a  hard 
disk   system,    C   language   and   SQL  database  management   system. 
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5.  Produce  a  "proof  of  concept"  prototype  of  high  resolution 
graphics    routines   for  improving    FAMIS   geodata   support. 

6.  Produce  a  database  system  that  is  capable  of  passing  NUDET 
geodata  to  FAMIS  in  latitude  and  longitude  format  from  input  in 
location,    direction   and   offset  format. 
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INTRODUCTION 


The  Office  of  the  Manager  of  the  National  Communication  System 
(NCS)  requires  timely  accurate  information  about  communications  re- 
sources during  national  disasters.  This  led  to  the  realization  that  an 
automated  decision  support  system  (DSS)  could  be  useful  to  the  National 
Emergency  Management  teams.  These  teams  will  play  control  the  moni- 
toring  and    resolution   of  claims  on   the  system. 

Meeting  these  requirements  is  the  task  of  the  integrated  emergency 
preparedness  management  information  system  (EPMIS)  and  the  fly-away 
management  system  (FAMIS).  They  are  an  integral  part  of  the  national 
telecommunications  management  system.  This  system  will  be  an  inte- 
grated system  of  mainframe  and  microcomputers.  The  mainframe  com- 
puters contain  the  information  necessary  to  reconstruct  the  national 
communication  system.  Analysts  in  the  field  use  microcomputers  to  pro- 
cess the  information  that  they  will  need  in  the  reconstruction  of  the 
system. 

The  system  is  still  in  the  early  design  stages.  This  report  covers 
mostly  the  FAMIS  portion  of  the  system.  Of  necessity,  however,  it  also 
includes  material  on  the  integration  with  EPMIS.  The  FAMIS  system 
currently  exists  as  a  prototype.  This  prototype  was  written  in  BASIC 
and  implemented  on  portable  Otrona  microcomputers.  The  present  sys- 
tem is  a  decision  support  system  of  the  file  drawer  variety.  It  is  used 
solely  for  information  retrieval.  Eventually,  information  analysis  and 
expert   system   capabilities   will    be   necessary. 

The  FAMIS  prototype  is  obviously  in  an  early  stage  of  development. 
Many  enhancements  are  needed  to  make  it  a  feasible  system  for  produc- 
tion use.  The  prototype  has  been  a  useful  learning  tool  for  defining 
the  final    system.      The   prototype   has   generated    interest   in    the   project. 

Now  that  the  concept  has  been  approved  it  is  time  to  move  beyond 
the  prototype  stage.  A  disciplined  development  effort  is  required.  The 
remainder  of  this  report  deals  with  the  definition  of  the  problem  and 
the   process   of   setting    up   a   disciplined   development   effort. 


-    1 


2 

CURRENT  FAMIS  CAPABILITIES 


The  FAMIS  microcomputer  systems  is  a  2,700  line  BASIC  program. 
It  is  written  in  GW-BASIC,  an  MS-DOS  dialect.  This  is  because  the 
system  uses  the  Otrona  portable  microcomputer.  GW-BASIC  is  similar 
to  IBM's  advanced  BASIC.  Judging  from  the  dates  on  the  disks  we  re- 
ceived, development  stopped  in  late  1983  or  early  1984.  Little  docu- 
mentation is  available  beyond  one  document  from  NCS  [National  Commu- 
nications System,  August  1983]  which  listed  the  menus  and  brief 
descriptions  of  their  functions. 

The  best  way  to  examine  the  system  is  to  look  at  the  menus.  These 
show  the  functions  and  what  they  do.  The  main  menu  for  the  system  is 
below. 


FAMIS   Main   Menu 


1.  P.O.C.    Lists 

2.  Emergency   Activation    Procedures 

3.  Network   Status   Monitoring 

4.  Damage  Assessment 

5.  Resolution   of   Claim 

6.  Zooming 

7.  Word    Processing    (WordStar) 

8.  NSC    Processing   Module 


Item  1  is  point  of  contact  list.  This  option  allows  the  user  to  get 
the  primary  point  of  contact  for  various  government  and  private  agen- 
cies. The  program  returns  the  point  of  contact  name,  address,  phone 
number,  and  alternative  means  of  contact.  There  is  currently  no  formal 
means  of  updating  these  point  of  contact  lists.  It  is  possible  to  update 
the  list  using  the  word  processing  selection  later  in  the  menu.  To  do 
this  effectively  the  user  would  have  to  know  a  lot  about  the  data  struc- 
tures employed  by  the  system.  Even  then  it  would  be  a  risky  process. 
There  is  too  much  chance  that  a  novice  would  damage  the  database  and 
render  the   system   inoperable. 

Item  2  is  emergency  activation  procedures.  This  option  displays  in- 
structions for  activating  the  emergency  procedure.  It  includes  informa- 
tion on  a  conditions  required  before  activation  of  the  NCS.  This  option 
is   a    reference  manual   of   procedures   for  the  field   analyst   using    FAMIS. 

Item  3  is  network  status  monitoring.  Selection  of  this  item  gener- 
ates graphic  views  of  the  status  of  government  and  commercial  communi- 
cations networks.  This  can  be  done  at  either  the  national  or  regional 
level.  Map  displays  show  connectivity  and  current  damage  status  of 
major  switching   centers. 

Item  4  is  damage  assessment.  This  selection  allows  the  user  to  up- 
date the  current  network  status  data.  The  user  may  add  information 
on  observed  or  predicted  damage  to  network  switching  centers  or  com- 
munication   nodes. 

Item  5  is  resolution  of  claim.  This  option  has  not  yet  been  imple- 
mented. Presumably  it  will  allow  the  user  to  request  that  a  particular 
node  or  communications  link  be  reestablished  or  modified.  This  request 
is  called  a  claim  and  all  claims  are  held  by  the  system  and  are  available 
to  be  listed  for  the  user.  A  major  task  of  the  NCS  is  to  assign  a  prior- 
ity  to  claims   on   the   system. 

Item  6  is  zooming.  This  feature  was  not  provided  in  the  material  we 
received   from   NCS. 

Item  7  is  word  processing.  The  word  processing  is  not  built  into 
the  FAMIS  system.  Word  processing  is  implemented  by  calling  an  ex- 
ternal word  processor.  Here  the  system  calls  WordStar.  This  feature 
will  not  work  on  the  IBM  advanced  BASIC  version  2.0.  It  requires  the 
SHELL  command  which  does  not  exist  in  IBM's  advanced  BASIC  2.0. 
This  feature  is  in  IBM's  BASIC  3.0.  With  this  selection,  a  user  can 
edit  external  files.  It  is  used  to  modify  the  database  or  compose  mes- 
sages. 
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The  final  menu  item  is  the  NSC  processing  module.  Its  purpose  was 
not  explained  in  the  documentation  we  received.  Presumably  it  gives 
contacts  on  the  National  Security  Council.  Perhaps  the  data  is  too  sen- 
sitive for  general   circulation. 

Using  a  prototype  has  enabled  NCS  to  field  a  version  of  the  FAMIS 
system  faster  than  using  a  traditional  systems  life  cycle.  The  proto- 
type is  similar  to  the  final  product.  It  has  been  useful  to  generate  in- 
terest  in   the   project. 

Nevertheless,  the  prototype  has  many  problems.  Its  usefulness  is 
at  an  end.  The  system  was  written  in  BASIC,  an  interpreted  language. 
This  allowed  for  fast  development  because  compiling  and  link  editing 
were  unnecessary.  This  is  the  only  good  news  about  BASIC.  Every- 
thing else  is  bad  news.  Because  it  is  an  interpreted  language,  it  is 
slow.  Non-programmers  designed  BASIC  for  use  by  non-programmers. 
It  is  presumably  easy  to  learn.  That  may  be  true  but  it  is  also  hard  to 
use.  The  language  is  unstructured.  Programs  in  BASIC  are  extremely 
difficult  to  maintain.  Data  handling  is  slow  and  clumsy.  It  does  not 
lend  itself  to  sophisticated  file  and  data  base  techniques  common  to 
modern    languages   like  C  or   PASCAL. 

As  is  usual  in  a  prototype,  there  are  many  errors  in  the  system. 
There  are  occasional  unexplained  abends.  Many  of  the  features  present 
in  the  menus  are  not  yet  implemented.  Some  of  the  features  present 
are  incorrect.  This  is  true  in  the  the  map  oriented  systems.  In  the 
damage  assessment  modules,  map  displays  do  not  work  properly.  A 
rectangular  damage  area  fails  to  plot  properly.  The  code  needs  to  be 
thoroughly  rewritten  and  tested.  I  suspect  the  map  uses  a  conical  pro- 
jection and  the  rectangular  damage  areas  use  a  Mercator  projection. 
Clearly  the   system   needs   a   more   sophisticated   geodata   display. 

There  are  additional  problems  with  this  system.  It  is  largely  undo- 
cumented. The  only  documentation  is  a  listing  of  screen  displays  and 
menus.  The  program  itself  is  mostly  uncommented.  This  may  be  nec- 
essary since  BASIC  is  an  interpreted  language.  By  using  few  com- 
ments, the  interpreter  does  not  waste  time  processing  comments.  But, 
it  makes   the   resulting   product   nearly    impossible  to   maintain. 

Because  of  the  limited  length  of  BASIC  variable  names,  it  is  difficult 
to  design  data  names  for  mnemonic  value.  This  makes  it  hard  for  main- 
tenance programmers  to  determine  what  is  going  on  with  data  handling. 
Finally,  the  program  uses  several  questionable  practices  to  accomplish 
its  ends.  One  example  is  the  menu  item  that  allows  the  user  to  exit  to 
WordStar.  This  gives  the  user  free  range  to  change  values  in  data  files 
and  fields.  The  system  is  complicated  enough  for  an  experienced  pro- 
grammer or  data  analyst.  One  would  not  want  to  turn  an  inexperienced 
user   loose  on   these  data   files.      The   result  can   only   be  disaster. 
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2.1  ANALYSIS  STEPS  TAKEN 

In  analyzing  this  system  I  had  two  major  goals  in  mind.  The  first 
was  to  speed  up  the  existing  system  for  demo  purposes.  The  second 
goal  was  to  analyze  the  system  to  determine  the  features  or  changes 
needed  for  future   revisions. 

I    took   several    steps   to   see   if    I    could   speed    it   up.      They    included: 

1.  Rewriting   portions   of  the   system. 

2.  Moving  the  system  to  a   hard   disk. 

3.  Developing   techniques   to   speed    up   the  graphics. 

4.  Compiling   a   portion   of  the  code. 

5.  Running    a    compiled    system    using    an    80186    based    accelerator 
board. 

6.  Rewriting   a   portion   of   the  code   in    C. 

7.  I  nvesitgating   data    base  management   systems   for   both    EPMIS   and 
FAMIS. 

These  approaches  offered  some  help.  Moving  the  system  to  a  hard 
disk  was  useful.  The  major  benefit  was  that  the  user  no  longer  had  to 
worry  about  swapping  floppy  disks.  The  necessary  files  were  automati- 
cally loaded  off  the  hard  disk.  There  was  a  slight  increase  in  speed 
(perhaps  by  a  factor  of  2).  But,  the  system  was  so  slow  to  begin  with 
that  this  could  hardly  be  called  major.  Compiling  the  system  using  a 
Microsoft  BASIC  compiler  helped  much  more.  Unfortunately  the  Micro- 
soft BASIC  compiler  is  limited  to  64K.  I  could  not  compile  the  complete 
system.  I  was  able  to  compile  the  main  driver  module  and  the  damage 
assessment  module.  The  damage  assesment  module  contains  the  most 
detailed  graphics.  I  figured  that  this  is  an  important  routine  that  com- 
pilation should  speed  up.  The  compiled  version  of  the  code  runs  some- 
where between  5  and  10  times  faster  than  the  floppy  disk  version. 
This    is   good   but   still    not   acceptable. 

Next  I  tried  to  speed  up  the  graphics.  The  NCS  programs  perform 
graphics  a  point  at  a  time  using  the  BASIC  graphics  commands.  This 
means  that  it  may  take  as  much  as  a  minute  to  generate  a  map  of  the 
United  States  and  communications  facilities.  It  may  not  sound  like  much 
but  it  is  painfully  slow  sitting  in  front  of  a  computer.  Even  in  inter- 
preted BASIC  it  is  possible  to  achieve  speeds  much  faster  than  this. 
This  is  done  by  using  the  BSAVE  and  BLOAD  commands.  This  makes  it 
possible  to  generate   a    screen    in   about  three   seconds. 
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The  same  screen  graphics  capabilities  are  available  in  other  lan- 
guages. Using  C,  it  is  possible  to  generate  screens  in  about  a  tenth  of 
a  second.  The  disadvantage  of  this  approach  is  that  the  entire  screen 
must  be  saved  on  a  file.  A  graphics  screen  requires  16K  of  storage 
space.  This  might  be  a  problem  on  a  floppy  disk  based  system.  On  a 
hard  disk  system  it  is  no  problem  at  all.  Since  hard  disk  systems  are 
cheap,  future  designs  for  FAMIS  should  assume  hard  disk  or  laser  disk 
storage.      There   is    no  point   in    locking   into  the  older  technology. 

Running  the  compiled  version  of  FAMIS  using  an  80186  based  accel- 
erator board  produced  dramatic  increases  in  speed.  Menus  and  graph- 
ics are  generated  quickly.  The  FAMIS  system  makes  heavy  demands  on 
a  microcomputer.  Future  versions  of  this  system  should  use  faster  chips 
than  the  old  8088  technology.  The  same  comment  applies  here  as  applied 
to  disks.      Design   the  system   using   that  best  technology   available. 

Rewriting  a  portion  of  the  code  in  C  gave  the  biggest  increase  in 
speed.  A  structured  language  like  C  or  PASCAL  is  simply  better  suited 
to  this  kind  of  problem.  In  addition,  C  offers  much  greater  availability 
of  sophisticated  program  libraries  than  BASIC.  These  libraries  have 
functions  for  screen   formatting,    graphics   and   data   base. 

The  final  step  was  the  investigation  of  data  base  management  sys- 
tems (DBMS).  In  the  prototype,  a  change  to  a  data  structure  requires 
a  change  to  the  program.  The  major  benefit  of  a  DBMS  is  that  it  allows 
program-data  independence.  One  can  change  file  structures  without 
reprogramming.  There  are  several  DBMS  that  are  interoperable  on  minis 
and   micros,    Unfortunately,    none  of  them  work  with    BASIC. 


2.2  CONCLUSIONS 

For    the    short    run,     there    are    several    things    that    can    be    done    to 
make  the   prototype  more   useful.      They   are: 

1  .  Compile   it. 

2.  Move   its   programs   and   data   to  a    hard   disk. 

3.  Run    it  on   a   faster  processor. 

4.  Use   stored   graphics   geodata. 

This  means  the  Otrona  microcomputers  have  outlived  their  usefulness. 
A  more  useful  computer  would  be  a  Compaq  with  a  hard  disk.  Unfortu- 
nately,   this    computer    will    be    be    obsolete    within    a    year    or   two.       They 
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will  be  replaced  by  portable  systems  using  faster  chips,  larger  hard 
disks,  and  laser  disks.  All  this  is  normal  in  such  fast  moving  technol- 
ogy. 

Running  the  prototype  on  a  more  powerful  machine  would  merely  be 
a  cosmetic  change.  It  is  the  technical  eqivalent  of  putting  a  Model  T 
engine  in  a  Porsche  body.  We  can  make  the  prototype  run  faster,  but 
it  cannot  be  easily  expanded  or  modified.  BASIC  has  too  many  faults 
for  a  production  version  of  FAMIS.  We  should  take  our  lessons  from 
the   BASIC   prototype  and   move  on. 

The  drivers  for  the  screens  and  graphics  should  use  a  compiler  lan- 
guage. The  data  structure  should  be  implemented  on  a  compatible  data 
base  management  system  (DBMS).  The  system  should  use  a  language 
and  data  base  system  that  is  interoperable  with  the  mainframe  system. 
This  would  allow  a  system  that  is  more  powerful,  more  flexible,  and 
more   reliable  than   the  current   prototype. 
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3 

DEFINING   DECISION  MODULES 


The  steps    required   are: 

1.  Review     and     if     necessary,     revise    the    goals     of    the    combined 
EPMIS/FAMIS   systems. 

2.  Design   the  decision   modules   needed  to  support  the  goals. 

3.  Identify  the  data   needed  to   support  the  decision   modules. 

4.  Select   the    hardware   and    software   configuration    needed    to    sup- 
port the   system. 

5.  Begin    work    on    the    system    using    a    disciplined    prototyping    ap- 
proach   rather  than   the  full    systems    life  cycle  approach. 

The  first  step  should  be  to  identify  the  decision  and  data  components  of 
the  decision  support  system  (DSS).  The  most  important  investment  in 
the  project  so  far  is  not  the  BASIC  prototype  program.  It  is  the  data 
and  the  sources  of  data  that  are  used  by  the  prototype.  If  the  manag- 
ers of  the  project  do  not  take  steps  soon  to  create  a  formal  data  struc- 
ture and   data   gathering    system,    this    intellectual   capital   will   be   lost. 

An  important  step  in  this  process  is  data  design.  It  is  necessary  to 
identify  the  data  needed  to  support  decisions  made  by  the  system.  It 
is  also  necessary  to  develop  models  and  decision  aids  needed  by  the  an- 
alysts to  reconstruct  the  communications  system.  Once  we  define  the 
data  structure,  we  need  to  design  the  data  distribution.  This  also  in- 
cludes designing  networks  for  communications  between  the  center  and 
field   analysts. 

The  issue  of  hardware  and  software  presents  a  dilemma  for  the 
EPMIS/FAMIS  system  design.  Typically,  hardware  and  software  selection 
are  done  after  the  data  design  and  decision  design  components  of  the 
system  are  completed.  But,  hardware  and  software  for  this  type  of 
DSS  is  changing  rapidly.  Any  decisions  made  now  are  likely  to  be  ob- 
solete in  a  short  time.  The  decision  requirements  will  change  constant- 
ly as  well.  Managers  must  realize  that  this  system  will  never  be  com- 
plete.      It  will    always   be  evolving. 
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There  are  many  developments  coming  up  soon  that  will  impact 
EPMIS/FAMIS  design.  Examples  include  high  quality  laser  disc  systems, 
faster  microcomputers,  better  graphics,  and  expert  systems.  The  most 
important  thing  is  to  create  a  flexible  logical  design  for  the  system.  We 
can  find  hardware  and  software  to  carry  out  the  logical  design.  If  we 
concentrate  first  on  hardware  and  software  design  then  the  logical  de- 
sign   issues   are   likely   to   be   lost. 

It  is  necessary  to  set  up  an  administrative  infrastructure  to  support 
the  operation.  I  would  place  the  offices  of  data  administrator  and  of 
systems  administrator  at  the  top  of  the  list.  The  data  administrator  acts 
as  the  custodian  and  keeper  of  the  data  in  the  system.  Much  of  the 
data  is  highly  volatile.  Information  is  included  on  points  of  contact  and 
procedures.  These  change  rapidly  and  is  the  responsibility  of  the  data 
administrator  to  track  these  changes   and   enter  them   into  the   system. 

This,  means  that  NCS  must  create  a  data  collection  system.  It  is 
necessary  to  identify  the  sources  of  data  and  to  keep  the  data  current. 
One  might  use  techniques  such  as  a  computerized  tickler  file  to  send 
out  letters  to  monitor  changes  in  the  system.  The  data  in  the  proto- 
type is  out  of  date.  This  is  not  surprising  since  it  is  about  two  years 
old.  If  20%  of  the  points  of  contact  change  every  year  (probably  low), 
the  data   has   a   three  year   half-life. 

The  responsiblity  of  the  data  administrator  is  to  track  this  data  and 
see  that  it  is  current.  The  responsibility  of  the  systems  administrator 
is  to  keep  abreast  of  technical  developments  that  affect  the  system. 
This  responsibility  includes  monitoring  the  design  of  both  the  EPMIS 
and  FAMIS  sides  of  the  system.  This  means  tracking  technical  develop- 
ments that  would  affect  either  system.  The  systems  administrator  is  in 
charge  of  the  configuration    and   development  of   the   system. 

The  hardware  and  software  in  the  systems  must  be  easy  to  maintain 
and  technically  current.  The  software  and  data  structures  should  be 
be  usable  across  machine  lines.  This  is  not  easy,  but  micros  and  minis 
are  evolving  so  that  it  is  possible.  As  microcomputers  become  more  so- 
phisticated, they  share  many  systems  with  their  larger  cousins.  A  de- 
sign goal  of  the  EPMIS/FAMIS  system  should  be  to  use  the  same  pro- 
grams  and   data   structures   on    both    systems. 
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CHOOSING  SOFTWARE 

The  hardware  and  software  decisions  must  support  the  overall  sys- 
tem goals.  The  EPMIS/FAMIS  managers  must  not  fall  into  the  trap  of 
the  traditional  systems  development  life  cycle.  The  life  cycle  model 
views  a  computer  system  as  a  solution  to  a  problem.  We  encounter  a 
problem.  We  analyze  it.  We  design  a  system  to  solve  it.  Finally,  we 
implement  that  system  on   a   computer. 

This  may  work  well  enough  when  working  with  simple,  bounded 
problems.  These  are  not  the  problems  that  the  EPMIS/FAMIS  system  is 
intended  to  solve.  These  systems  are  decision  aids  for  an  unstructured 
enviroment.  System  requirements  will  continue  to  evolve  over  the  life 
of  the  system.  If  we  try  to  state  them  fully  at  the  beginning,  we  will 
never  finish.  Daniel  McCracken  and  Michael  Jackson  [1982,  p.  30] 
stated  the  problem   best. 

The  life  cycle  concept  perpetuates  our  failures  so  far,  as 
an  industry,  to  build  an  effective  bridge  across  the  com- 
munications gap  between  end-users  and  systems  an- 
alysts. In  many  ways  it  constrains  future  thinking  to  fit 
the  mold     created   in      response  to     failures   of     the  past. 

In  this  system,  we  should  make  our  software  decisions  first.  Then, 
we  can  find  hardware  on  which  to  implement  this  software.  The  soft- 
ware goals   should   be: 

1.  The     software     should     be     portable     across     machine     lines.        It 
should   be   useable  on    both   micros   and   minis. 

2.  The    software    should    be    reasonably    fast.       The    user    should    not 
have  to  wait  forever  for  text  or  graphics  output. 
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3.  The  software  should  support  a  DBMS.  We  must  design  our  ap- 
plications so  that  data  and  programs  are  independent.  This  is 
a  major  goal  of  a  DBMS.  If  programs  and  data  are  not  indepen- 
dent,   maintenance  and   enhancement   is   almost   impossible. 

4.  The  language  chosen  for  the  software  should  be  a  structured 
language   suitable  for  modern    programming   practices. 

5.  The   software   should   support  queries   by    untrained    users. 

This  is  a  formidable  set  of  requirements.  The  language  chosen  must 
allow  for  fast  development.  It  will  have  to  support  sophisticated  appli- 
cations like  graphics  and  data  base.  At  the  same  time  it  will  have  to 
support   untrained    users. 

To  choose  a  language,  we  must  examine  the  choices  available  on 
both  microcomputers  and  minicomputers.  The  first  language  we  will  ex- 
amine is  BASIC.  BASIC  stand  for  Beginners  All-Purpose  Symbolic  In- 
struction Code.  It  was  invented  at  Dartmouth  in  1964  and  it  evolved 
continuously  since  then.  It  is  widely  available  on  many  classes  of  com- 
puters.     The  advantages   and   disadvantages   of    BASIC   are   listed    below. 


BASIC   -   Advantages 

1.  BASIC    is   somewhat   standardized. 

The  implementations  available  on  microcomputers  and  minicom- 
puters have  many  features  in  common.  Programmers  could 
move  from  one  environment  to  the  other  without  having  to  rel- 
earn   the   language. 

2.  BASIC   is   easy   to   learn. 

Most  people  can  write  simple  programs  in  a  few  hours.  In  a 
few  weeks   they   are   able  to   do  complicated    programs. 

3.  BASIC   is   an    interpreted    language. 

This   means   that   it   is   fast   to  write  and   change   programs. 

4.  Compilers   are  available  for   BASIC. 

The  interpreted  programs  can  be  translated  into  object  modules 
which    run   much   faster  than   the   interpreted   version. 

5.  Programmers    in    BASIC   are  widely   available. 
Most   programmers    know    BASIC. 
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BASIC-Disadvantages 

1.  BASIC   is   slow  to  execute. 

A  large  program  in  interpreted  BASIC  can  be  painfully  slow. 
Even  compiled  BASIC  is  slower  than  compiled  versions  of  more 
sophisticated    languages. 

2.  BASIC   is   unstructured. 

It  does  not  support  constructs  like  the  I F-THEN-ELSE,  the 
DO-WHILE  or  the  PERFORM-UNTI L.  Some  versions  of  BASIC 
have  these  constructs.  But,  these  versions  of  BASIC  sacrifice 
portability.  Because  it  is  unstructured,  BASIC  encourages  the 
worst  possible  programming  habits.  Programs  written  in  BASIC 
are   nearly   impossible  to  maintain. 

3.  BASIC   is    hard   to   use. 

This  sounds  paradoxical  since  an  advantage  of  BASIC  is  that  it 
is  easy  to  learn.  Easy  to  learn  does  not  mean  easy  to  use. 
Programs  written  in  BASIC  quickly  become  unmanageable.  A 
programmer  quickly  loses  control  of  the  program.  When  the 
size  of  a  program  goes  much  above  a  hundred  lines,  there  is 
little   hope  of  cleaning   it   up. 

4.  BASIC's   data   handling  features   are  poor. 

Beginning  students  seldom  deal  with  large  amounts  of  data. 
This  may  not  be  a  handicap  for  teaching,  but  it  is  a  handicap 
for  use  with  the  EPMIS/FAMIS  systems.  BASIC's  lack  of  a  re- 
cord   structure  makes   it  extremely   difficult  to   handle  data. 

5.  BASIC   does    not  support  data   base  management   systems. 

It  is  either  difficult  or  impossible  to  link  from  BASIC  to  DBMS 
available  on   the   same  machines. 

The  next  choice  of  language  is  COBOL.  COBOL  stands  for  Common 
Business  Oriented  Language.  It  was  defined  by  a  joint  committee  of 
users  and  Department  of  Defense  in  1959.  COBOL  is  widely  used  for 
data  processing  in  both  government  and  the  private  sector.  The  ad- 
vantages  and   disadvantages   of   COBOL  are   listed   below. 


COBOL-Advantages 

1.  COBOL   is   a   standardized    language. 

The  versions   available  on    many   different   systems   are   similar. 

2.  COBOL   is   a   data   processing    language. 
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It  is  ideally  suited  for  handling  fields  and  records.  It  has  a 
wide  variety  of  editing  functions   built   in. 

3.        There  are  many   programmers   available  who   know   COBOL. 

It  is  not  as  widespread  as  BASIC,  but  it  is  the  language  of 
choice  in  the  commercial  programming  world.  It  is  not  difficult 
to  find   programmers   familiar  with   this    language. 


COBOL- Disadvantages 

1.  COBOL   is   an   old   fashioned    language. 

It  does  not  support  some  of  the  modern  control  structures.  It 
is  also  difficult  to  break  a  COBOL  program  up  into  modules  or 
subroutines. 

2.  COBOL  does    not   support  data    base  well. 

It  handles  data  well  in  a  file  processing  environment.  The 
links   to  a   data   base  may  or  may    not   be  available. 

3.  COBOL   is   slow. 

4.  COBOL   has   a   poor  to   non-existent  mathematics   capability. 

If  your  problems  require  any  numeric  processing,  COBOL  is  a 
poor  choice. 

5.  COBOL   is    intended   for   batch    processing   operations. 
It   supports    screen-oriented   on-line  operations   poorly. 

FORTRAN  is  the  next  language  to  consider.  FORTRAN  stands  for 
Formula  Translator.  It  is  an  old  language,  developed  at  IBM  in  the 
1950's.  It  is  since  become  the  standard  language  for  scientific  process- 
ing. It  is  available  on  minicomputers,  mainframes  and  micros.  The  var- 
ious versions  of  FORTRAN  are  usually  quite  compatible.  It  is  an  easy 
language  to  transfer  across  machines.  In  spite  of  this,  FORTRAN  is 
uncommon  on  microcomputers.  The  advantages  and  disadvantages  of 
FORTRAN   are   summarized    below. 


FORTRAN -Advantages 

FORTRAN     is    a     standardized     language    that    moves    easily    from 
machine  to  machine. 

There  are  many   programmers   available  for   FORTRAN. 
Until    recently,    FORTRAN    was   the  first   language   that   most   peo- 
ple  learned.       It   is    since   been    supplanted   by    BASIC. 
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FORTRAN    has   excellent  mathematical   processing   capabilities. 
There  are  many   mathematical    libraries   available  for   FORTRAN. 

FORTRAN    is   well  suited  to  minicomputers   and   mainframes. 


FORTRAN -Disadvantages 

1.  FORTRAN    is   an   old   fashioned   language. 

The   older    versions    of    it    are    the    most   transportable,    and    they 
do   not  support  structured   programming   constructs. 

2.  FORTRAN    has   poor  data   handling  features. 

It   does    not    support    record    structures    at   all.      String    manipula- 
tion   in    FORTRAN   can    be  maddening. 

3.  FORTRAN    usually  does   not  support   interface  to   DBMS. 

4.  FORTRAN,    like    COBOL,    is    not   well    suited    for    screen    oriented 
operations . 

The  next  language,  C,  was  developed  at  the  Bell  Telephone  Labora- 
tories in  the  late  1960's  and  early  1970's.  It  is  a  simple,  yet  powerful, 
structured  programming  language.  It  allows  users  to  perform  systems 
programming  activities  without  having  to  resort  to  assembly  language. 
The  advantages   and   disadvantages  of   C   are   summarized   below. 


C    -   Advantages 

1.  The  various   versions   of   C   are   standardized   and    stable. 

The  language  was  invented  to  facilitate  transfer  of  programs 
from  one  type  of  machine  to  another.  It  performs  this  function 
well . 

2.  C   is   a   structured   language. 

It   has   the  full    range  of   structured   constructs. 

3.  C    has   powerful   features. 

These  range  from  record  oriented  constructs  at  the  top  level 
down   to  constructs   that  allow  you   to  manipulate  bits   and   bytes. 

4.  There   is   a   wide  choice  of   support   libraries   available  for   C. 
These    include    libraries    for    mathematics,    graphics,    screen    han- 
dling  and    language  extensions. 
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C  is  the  language  of  choice  on  microcomputers  and  minicomput- 
ers. 

Many  of  the  systems  available  on  microcomputers  are  written  in 
C.  Much  the  same  is  true  on  minicomputers.  On  Digital 
Equipment  Corporation's  PDP-11  and  VAX  systems,  C  is  the 
language   used   to   implement  the   UNIX  operating   system. 

C  offers   interfaces   to   DBMS. 

Many    of    the    DBMS    available    on    microcomputers    are    written     in 

C. 

Interpreters   are  available  for  C. 


C-Disadvantages 

1.  C   programmers   are   hard   to  find. 

A  recent  issue  of  the  Government  Computer  News  noted  that  C 
programmers  in  the  Washington,  D.C.  area  frequently  receive 
five  figure  raises  when  changing  jobs.  This  is  because  C  is 
the  ianguage  of  choice  for  implementing  military  command  and 
control  systems  and  sophisticated  systems  software.  Program- 
mers  of  this  type  are   in   demand. 

2.  C   is    not  a   language  for  beginners. 

It   requires    sophistication    and   skill    in    programming. 

The  next  language  is  PASCAL.  PASCAL  was  developed  by  Nicholas 
Wirth  in  Zurich,  Switzerland  in  the  1970's.  It  is  named  after  Blaise 
Pascal,  the  French  mathematician,  PASCAL  is  intended  to  be  an  in- 
structional language.  It  encourages  structured  programming  habits. 
The  language  has  grown  in  popularity  since  its  invention.  It  now  is 
the  language  of  choice  for  beginning  instruction  in  Computer  Science. 
It  has  replaced  BASIC  for  serious  computing  instruction.  It  is  widely 
popular  on  microcomputers  and  minicomputers.  The  advantages  and 
disadvantages   of    PASCAL   are   summarized   below. 


PASCAL-Advantages 

1.  PASCAL  is  somewhat  standardized.  It  is  widely  available  on 
mainframes,  minicomputers  and  microcomputers.  The  versions 
on  different  machines  differ  somewhat.  This  can  be  annoying 
but,    generally,    it   is    not   serious. 

2.  PASCAL  is  a  structured  language  and  offers  a  wide  variety  of 
powerful   features. 
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3.  The   language   is   widely  available  on   mini   and   microcomputers. 

4.  PASCAL  programmers   are   readily  available. 

Most   computer    science    students    from    good    programs    have   done 
their  work   in    PASCAL. 


PASCAL- Disadvantages 

1  .  PASCAL  has  a  narrower  range  of  support  packages  than  is 
available  in   C. 

2.  There  are  usually  no  special  interfaces  to  DBMS  in  PASCAL, 
although  one  could  probably  modify  C  interface  techniques  to 
work. 

3.  There  are   no   PASCAL   interpreters   available. 

This  may  be  less  of  a  problem  than  it  seems.  The  most  popu- 
lar version  of  PASCAL  on  microcomputers  is  Borland's  Turbo- 
PASCAL.  Turbo  is  a  compiler  but  it  operates  fast  enough  that 
it   is   as   easy   to   use  as   an    interpreter. 

4.  PASCAL  is  slower  than  C  because  of  the  strong  typing  of  vari- 
ables   used   to   support  the   instructional   mission   of  the   language. 

5.  The  versions  of  PASCAL  that  are  available  on  microcomputers 
do   not   support  the   large  memory   models. 

They  think  of  the  machine  as  a  64K  machine  and  cannot  use  the 
1    megabyte  and   larger  memories   on    newer  machines. 

The  next  language  is  FOCUS.  This  is  a  language  developed  in  the 
1970's  by  a  company  called  Information  Builders  Inc.  It  one  of  a  class 
of  languages  called  Fourth  Generation  Languages  (4GL)  or  Higher  Order 
Languages  (HOL)  [Harel  and  McLean,  1985;  Martin,  1982].  These  are 
integrated  languages  that  pre-dated  packages  like  Symphony  and 
Framework  by  10  to  15  years.  These  languages  allow  novices  to  use 
integrated  data  base  management  systems,  spreadsheet  modeling,  statis- 
tical   packages   and   graphics. 

Recently,  the  vendors  of  these  languages  have  begun  to  offer  their 
products  on  microcomputers  as  well  as  mainframe  computers.  One  de- 
sign goal  in  their  product  is  to  facilitate  data  and  program  transfer 
from  microcomputers  to  mainframe  and  minicomputers.  They  offer  the 
same  version  of  their  languages  in  both  environments.  The  advantages 
and   disadvantages   of   FOCUS   are   summarized   below. 
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1  .  FOCUS  is  an  integrated  system  available  on  both  micro  and 
minicomputers. 

2.  FOCUS   is   easy  to   learn. 

3.  FOCUS   supports   ad    hoc   queries    into  the  data   base. 

4.  .      FOCUS    supports    a    powerful    data    processing    programming    capa- 

bility. 

FOCUS-Disadvantages 

1.  The  system  is  large  and  clumsy.  On  a  microcomputer  it  re- 
quires 512K  of  memory  and  3  and  a  half  megabytes  of  the  hard 
disk. 

2.  FOCUS    is   slow. 

3.  FOCUS    is   business   data    processing   oriented. 

The    geodata     routines     required     by    the    EPMIS    and     FAMIS    will 
have  to   be   programmed    in    C. 
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5 
CONCLUSIONS 


Work  on  the  EPMIS/FAMIS  system  has  reached  a  critical  point.  NCS 
has  created  structures  to  gather  data  about  the  communications  sys- 
tems. It  has  made  a  start  on  a  system  to  store  this  data  in  computer 
readable  form.  Much  remains  to  be  done,  however.  Management  needs 
to  establish  a  clear  set  of  goals  and  priorities  for  the  system  develop- 
ment to  succeed.  Currently,  the  goals  of  the  project  are  unclear.  The 
computer  systems  supporting  the  project  reflect  this.  EPMIS/FAMIS 
system  cannot  succeed  until  NCS  has  a  clear  vision  of  its  mission.  It  is 
impossible  to  design  a  decision  support  system  without  a  clear  idea  of 
the  decisions   supported. 

In  one  sense,  this  may  never  be  possible.  EPMIS  and  FAMIS  gather 
information  and  support  decisions  in  an  unstructured,  chaotic  environ- 
ment. There  can  never  be  a  finished  system.  The  EPMIS/FAMIS  project 
will   always    have  to  operate   in   a   prototyping   mode. 

NCS  needs  to  assemble  a  flexible  programming  team  to  implement  this 
system.  This  system  team  must  also  be  highly  competent.  They  should 
be  able  to  design  implement  new  programming  and  data  structures 
quickly.  In  the  conditions  under  which  EPMIS/FAMIS  will  operate, 
there  will  be  no  time  for  a  complete  system  development  life  cycle.  A 
primary  design  goal  must  be  flexibility.  The  specific  recommendations 
for  the   EPMIS/FAMIS   system  follow. 

First,  establish  specific  goals  for  the  system.  The  EPMIS/FAMIS 
system  as  it  now  stands  is  simply  a  file  drawer  system.  It  stores  in- 
formation about  the  current  status  of  the  communications  system. 
FAMIS  operators  can  enter  status  changes  to  that  system.  The  system 
needs   to   be  able  to  do  more  than   this. 

The  NCS  managers  must  develop  means  for  setting  priorities  and  re- 
solving claims  on  the  communications  system.  EPMIS/FAMIS  should  offer 
support  for  these  decisions.  This  issue  is  politically  sensitive,  but  un- 
til it  is  resolved,  NCS  cannot  be  effective  in  an  actual  crisis  situation. 
NCS  must  have  well  defined  goals  to  implement  an  effective  decision 
support   system. 


Next,  it  is  necessary  to  design  decision  modules  to  implement  the 
goals.  Until  the  goals  are  clear,  the  nature  of  the  decision  modules  will 
not  be  clear  either.  The  simple  file  drawer  decision  support  system  has 
its  uses.  But,  more  sophisticated  decision  support  modules  are  needed. 
Examples  might  include  mathematical  programming  algorithms  to  help 
reestablish  connectivity.  Another  possibility  would  be  queueing  or  sim- 
ulation models  to  help  predict  actual  load  on  the  system.  Expert  system 
decision  modules  would  be  of  immense  help  in  codifying  the  rules  used 
to   resolve  claims   on   the  communications    system. 

Finally,  begin  design  of  a  database  to  support  the  decision  modules. 
The  current  system  is  not  a  database.  It  is  a  file  oriented  system. 
File  oriented  systems  were  common  in  the  third  generation  computer 
languages.  They  caused  the  structure  of  the  data  to  be  hopelessly  im- 
bedded in  programs.  If  the  data  structure  is  changed,  then  programs 
must  be  changed  as  well.  As  the  system  grows,  this  becomes  an  in- 
creasingly complex  task.  The  result  is  that  once  the  system  has 
reached  a  certain  size,  it  is  too  much  trouble  to  change  it.  The  system 
can  no  longer  expand.  Given  the  goals  of  the  EPMIS/FAMIS  system,  this 
would   be  disaster. 

The  solution  is  a  database  management  system.  The  best  choice 
would  be  a  relational  database  management  system.  Relational  database 
is  the  newest  technology  and  the  easiest  to  work  with.  Database  gives 
you  program-data  independence.  It  allows  expansion  of  the  database  to 
take   place   independently  of  the  programs. 

Work  on  data  design  should  begin  immediately.  Data  design  can 
take  place  before  choosing  a  database  management  system.  Eventually  a 
data  design  must  be  implemented  on  a  specific  database  management 
system.  Design  issues  are  independent  of  the  database  management 
system  (for  relational  systems),  so  the  specific  relational  system  chosen 
is  irrelevant.  The  first  step  in  data  design  is  to  establish  a  data  dic- 
tionary structure  to  capture  facts  about  the  data  base.  Facts  include 
field    names,    field    lengths,    field   types   and    sources   of  data. 

The  design  process  should  use  the  current  FAMIS  files.  These  files 
are  the  most  valuable  part  of  the  FAMIS  prototype.  They  serve  as  a 
guide  in  moving  from  a  prototype  system  to  a  production  system.  Be- 
gin immediately  to  isolate  the  data  items,  to  assign  them  reasonable  field 
names,    and   to   begin   the   data   dictionary   building. 

Once  the  data  dictionary  system  is  established,  we  can  begin  to  as- 
sign these  fields  to  files  or  relations.  The  relations  should  be  in  third 
normal  form.  This  allows  for  easy  modification  of  the  data  later.  Once 
the  data  structure  has  been  laid  down,  NCS  can  set  up  an  administra- 
tive   structure    for    data    capture.       The    data    that    makes    up    the    FAMIS 
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system  has  a  short  half  life.  This  half  life  is  almost  certainly  less  than 
three  years.  There  must  be  a  means  of  capturing  information  about 
changes  to  the  system. 

The  data  dictionary  system  will  serve  as  a  basis  for  tracking  chang- 
es. The  process  of  tracking  changes  should  be  automated  to  the  great- 
est extent  possible.  Using  the  FAMIS  data  dictionary  system,  one  could 
set  up  a  computerized  letter  generator.  This  system  could  periodically 
request  updated  information  from  the  relevant  agencies.  The 
EPMIS/FAMIS   system   is   only  as   good   as  the  data   making   it   up. 

As  part  of  this  project,  the  material  from  Booz,  Allen  and  Hamilton 
was  reviewed.  Booz,  Allen  and  Hamilton  has  produced  little  useful 
material  for  EPMIS/FAMIS  so  far.  Their  reports  are  mostly  rehashes  of 
standard  material.  They  are  only  marginally  useful  in  the  design  of  the 
EPMIS/FAMIS  system.  One  report  is  largely  a  program  listing  of  the 
FAMIS  prototype.  It  has  a  few  comments  about  the  program,  but  it  of- 
fers  nothing   new  or   useful. 

Two  other  reports  are  rewrites  of  standard  system  analysis  texts 
(the  book  by  Powers,  Adams  and  Mills,  1984  comes  to  mind  as  a  possi- 
ble source,  but  many  sources  are  possible).  The  material  has  been  re- 
written to  apply  to  the  NCS  situation.  There  is  nothing  wrong  with 
using  the  best  available  sources  in  a  report.  The  only  problem  with 
this  material  is  that  it  is  too  superficial  and  too  general.  Booz,  Allen 
and  Hamilton  should  have  provided  a  detailed  analysis  of  the  NCS  situ- 
ation . 

My  hypothesis  is  that  Booz,  Allen  and  Hamilton  have  not  received 
sufficient  guidance.  The  project  needs  to  be  better  defined.  What  they 
have  produced  is  a  reflection  of  the  current  state  of  the  EPMIS/FAMIS 
system.  They  seem  to  feel  that  the  FAMIS  system  could  remain  as  it 
is,  written  in  BASIC  and  implemented  on  the  Otrona  microcomputers. 
Considering  the  needs  of  the  FAMIS  system,  this  is  a  strange  recom- 
mendation. There  are  obviously  problems  with  FAMIS.  Booz,  Allen  and 
Hamilton  should  be  the  first  to  point  them  out.  I  doubt  that  they  have 
assigned  their  first  team  to  this  project.  Their  work  looks  like  a  term 
paper  in  an  MBA  Systems  Analysis  class.  To  use  high-priced  consult- 
ing talent,  one  must  provide  well-defined  tasks  with  explicit  delivera- 
bles . 

The  next  recommendations  deal  with  improvement  of  the  FAMIS  pro- 
totype. The  prototype  is  near  the  end  of  its  life  cycle.  It  is  useful  in 
the  short  term  for  demonstration  and  training,  but  it  is  not  a  produc- 
tion system.  Several  steps  can  be  taken  to  enhance  its  usefulness. 
These   include: 
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1.  Compile  the  system. 

It  is  possible  to  speed  the  system  up  by  a  factor  of  between  10 
and  20  by  compiling  it.  The  compiler  used  should  be  able  to 
use  all  available  memory.  Such  compilers  include  the  new  Micro- 
soft 3.0  version  of  BASIC  or  an  outside  compiler  like  the  Bet- 
ter  BASIC   compiler. 

2.  Move  the  system  to  a   hard   disk. 

The  current  system  uses  floppy  disks.  It  is  as  much  a  test  of 
the  manual  dexterity  of  the  operator  as  anything  else.  The 
continual  changing  of  floppy  disks  is  an  annoyance.  We  have 
put  the  system  on  a  hard  disk  at  the  Naval  Postgraduate 
School.  The  move  was  simple.  All  that  was  required  was  mod- 
ification  of  the  drive   reference  on   open    commands. 

3.  Implement  the   system  on   a   faster  microcomputer. 

An  80186  or  an  80286  based  machine  offers  a  noticable  improve- 
ment in  speed.  This  improvement  is  even  better  when  a  com- 
piled version  of  the  prototype  is  used.  These  chips  offer 
three  to  four  times  the  speed  of  the  conventional  8088.  The 
80286  or  80386  will  probably  be  the  target  chip  for  the  eventual 
FAMIS    system.      One  may   as   well    start  working   with   them' now. 

4.  Speed    up   the  graphics   on   the   system. 

The  graphics  on  the  FAMIS  system  are  painfully  slow.  They 
are  generated  a  point  at  a  time  using  the  BASIC  graphics  com- 
mands. Even  in  interpreted  BASIC,  it  is  possible  to  achieve 
faster  speeds  than  this.  One  can  use  the  BSAVE  or  BLOAD 
commands.  This  means  that  a  graph  that  requires  20  seconds 
to  generate  in  interpreted  BASIC  is  cut  to  3  seconds.  If  one 
uses  machine  language,  the  improvement  is  even  more  dramatic. 
The  three  seconds  required  by  the  BASIC  commands  can  be  cut 
to  one-tenth  of  a  second  or  less.  These  techniques  require  the 
use  of  16K  of  file  space  for  each  graphic  screen  saved.  This 
might  be  a  severe  limitation  on  a  floppy  disk  based  system.  On 
a    hard   disk   system   it   is    not   a    problem. 

5.  Use    the    prototype    system    as    a    test    bed    for    future    enhance- 
ments,   but   ultimately   abandon    it. 

The  prototype  has  outlived  its  usefulness  and  the  sooner  that 
its  lessons  can  be  moved  to  a  more  powerful  system,  the  bet- 
ter. 
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The  next  point  concerns  the  administration  of  the  EPMIS/FAMIS  sys- 
tems. Management  of  the  system  is  at  least  as  important  as  the  software 
and  hardware.  One  needs  to  develop  an  administrative  support  struc- 
ture. This  includes  both  the  data  and  the  programming  sides  of  the 
system.  For  the  data  side  of  the  system  it  is  necessary  to  develop  an 
information    resource  management  philosophy. 

The  first  step  should  be  to  appoint  a  database  administrator.  The 
primary  duty  of  the  database  administrator  is  to  maintain  configuration 
control  on  the  database.  It  is  this  person's  job  to  supervise  the  gen- 
eral structure  of  the  system.  The  database  administrator  should  oversee 
the  management  of  the  data  using  a  data  dictionary  system.  In  this  ac- 
tivity, the  database  administrator  will  have  several  subordinates. 
These  would  include  clerks  and  data  librarians.  It  is  the  function  of 
the  data  librarian  to  supervise  the  data  at  the  detail  level.  This  in- 
cludes such  duties  as  making  sure  that  the  data  is  updated  in  a  timely 
fashion . 

The  management  of  the  system  itself  is  as  important  as  the  manage- 
ment of  the  data.  To  give  this  system  the  flexibility  it  needs,  NCS  will 
have  to  have  a  staff  of  highly  competent  programmers.  These  individu- 
als will  have  to  be  managed  by  a  knowledgable  systems  manager.  Given 
the  way  the  federal  government  treats  technical  personnel,  this  may  be 
an  impossible  dream.  If  this  is  true,  then  EPMIS/FAMIS  is  an  impossi- 
ble dream  as  well.  It  will  be  the  responsibility  of  th£  system  manager 
to  maintain  configuration  control  over  the  EPMIS/FAMIS  system.  This 
individual  will  have  know  the  structure  of  the  whole  system  and  be  able 
to   supervise  technical    personnel. 

A  major  goal  of  the  EPMIS/FAMIS  system  should  be  a  high  degree  of 
interoperability  between  the  two  systems.  The  EPMIS  and  FAMIS  sys- 
tems should  use  the  same  languages.  This  will  reduce  the  cognitive 
load  on  the  programmers  working  on  the  systems.  It  makes  easier  to 
transfer  programs,  data,  and  storage  techniques.  A  few  years  ago,  this 
would  have  been  impossible.  Now  many  of  the  same  tools  used  on  main- 
frames are  being  transported  to  micros.  It  is  increasingly  common  to 
find   the   same   programming    languages    used   across   machine   lines. 

The  software  team  should  plan  to  operate  in  a  permanent  prototyp- 
ing mode.  This  will  have  to  be  a  disciplined  prototyping  mode  rather 
than  the  loose  and  sloppy  operation  that  characterized  the  original 
FAMIS  prototype.  Programmers  will  have  to  learn  to  document  as  they 
go,  to  use  structured  programming  techniques,  and  to  work  together  as 
a  team.  This  is  a  common  approach  among  programmers  operating  in  a 
UNIX  environment  on  systems  like  C.  It  was  obviously  not  the  ap- 
proach   used    in   the  original    FAMIS   prototype. 
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If  the  EPMIS/FAMIS  system  is  to  provide  support  in  chaotic  situ- 
ations, this  is  the  kind  of  team  that  is  required.  The  software  team  will 
have  to  develop  systems  quickly.  They  will  have  to  have  a  high  level  of 
technical  sophistication.  Given  the  environment  in  which  FAMIS  will 
operate,  it  is  not  possible  to  anticipate  all  demands  on  the  system  in 
advance.  Those  we  can  anticipate  should  be  built  into  the  system.  For 
the  others,  it  will  be  necessary  to  respond  quickly  to  changing  situ- 
ations  as   they   develop. 

NCS  needs  to  move  quickly  to  lay  a  hardware  and  software  founda- 
tion for  the  future.  The  decisions  made  now  will  determine  the  success 
of  the  EPMIS/FAMIS  system.  NCS  should  make  some  changes  to  the 
current  hardware  and  software.  First  is  to  choose  compatible  software 
for  EPMIS  and  FAMIS.  The  current  software  choices  are  C  and  Ingres 
for  database  for  EPMIS,  and  BASIC  and  the  IBM  PC  family  for  FAMIS. 
C  is  a  reasonable  language  given  the  sophisticated  requirements  of  this 
system.    It  operates   on   both   minis   and   micros. 

The  choice  of  INGRES  as  a  database  management  system  for  EPMIS 
also  has  problems.  INGRES  is  a  reasonable  database  management  lan- 
guage, but  it  does  not  exist  on  the  PC.  The  manufacturers  of  INGRES 
are  planning  to  have  a  PC  version  sometime  in  1986.  Other  database 
management  systems  have  this  option  available  now.  Another  disadvan- 
tage of  INGRES  is  that  it  is  not  the  direction  in  which  database  systems 
are  moving.  The  main  database  development  seems  to  be  headed  toward 
SQL. 

There  is  a  move  afoot  to  create  an  ANSI  standard  for  SQL.  This 
language  was  invented  at  IBM  and  is  available  from  several  manufactur- 
ers. The  best  choices  would  be  C  for  custom  applications,  SQL  for 
database  and  perhaps  FOCUS  for  applications  requiring  quick  quick  de- 
velopment. These  packages  are  available  on  both  mainframes  and  mic- 
ros. 

Once  we  have  chosen  compatible  software,  the  managers  of  the  sys- 
tem must  design  for  interoperability  between  the  VAX  and  micro  system. 
The  systems  should  use  the  same  programs,  database  management  sys- 
tem and  data  files.  This  will  make  for  faster,  cleaner,  and  cheaper  im- 
plementation   efforts. 

A  point  must  be  mentioned  about  the  FAMIS  database.  Strictly 
speaking,  none  of  the  data  in  the  database  is  classified.  But,  it  is  not 
something  that  one  would  want  to  fall  into  unfriendly  hands.  FAMIS  is 
an  easy  to  use  blueprint  of  the  U.S.  communications  system.  Moreover, 
in  times  war  or  national  emergency,  information  about  the  status  of 
communications  systems  would  be  classified.  Some  steps  should  be  taken 
for    protection    of    the    of    the    FAMIS    database.       The    database    should    be 
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encrypted.     The    data    provided    by    a    FAMIS    operator    could    be    used    to 
decrypt  the  data. 

The  final  point  involves  the  computers  used  by  FAMIS.  The  Otronas 
have  outlived  their  usefulness.  They  were  a  good  decision  at  the  time, 
and  now,  they  should  be  retired.  Their  replacement  should  be  a  hard 
disk  based  80826  system.  This  would  allow  for  greater  storage  capaci- 
ties and  speeds  in  the  FAMIS  system.  A  high  resolution  color  monitor 
would  also  be  desirable.  The  managers  of  the  EPMIS/FAMIS  system 
should  watch  developments  in  laser  disks  carefully.  The  geodata  dis- 
plays on  a  current  FAMIS  system  are  crude.  The  laser  disks  offer  the 
possiblility  of  extremely  sophisticated  geodata  capability.  This  would 
immeasurably   enhance  the  effectiveness  of  the   FAMIS   system. 

This  report  has  outlined  many  steps  that  the  managers  of  the 
EPMIS/FAMIS  system  should  consider.  The  managers  need  to  realize 
that  both  technical  and  administrative  changes  are  required.  There  is 
no  technical  quick  fix  for  the  problems  of  NCS.  A  cleaner  tighter  ad- 
ministration is  the  first  priority.  Without  that,  technical  changes  would 
be  of   no  benefit. 
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